The secure sockets layer (SSL) protocol (hereinafter, “SSL”) provides secure communication between two devices, typically a client and a server, through authentication of one or more of the devices, encryption of the communication to prevent eavesdropping, and an integrity check to prevent modification of the communication while it is in transit between the two devices. Much of the discussion below also applies to the transport layer security (TLS) protocol, the successor of SSL, other protocols that use X.509 certificates, and other protocols that use the Public Key Infrastructure (PKI), although for conciseness, the following discussion will focus on SSL.
As depicted in FIG. 1, SSL begins with a handshake between the client 10 and the server 30, and is followed by a bulk data transfer between the two devices. In the handshake, the client 10 sends a “client hello” message (i.e., a connection request) that lists the ciphers supported by the client (step 102). The server responds with a “server hello” message that records the strongest cipher (out of the client's list) that is supported by the server (step 104). In addition, the server transmits a digital certificate, which binds an identity of the server (e.g., the server name) to a public key of the server (step 104). The server certificate is typically issued by a certificate authority (CA) which certifies the authenticity of the server certificate by signing the server certificate with its private key.
In the case of mutual authentication, the server may also require client authentication (e.g., required for some on-line banking operations), and if so, sends a client certificate request to the client (step 104). The client verifies that the server certificate is valid by verifying the CA's signature (e.g., decrypting the encrypted CA signature with the CA's public key), and verifying that the CA is listed in the client's list of trusted CAs (step 106). If the certificate is valid, the client generates a master secret (also called a secret key), encrypts it with the server's public key, and sends the result to the server (step 108). If the server requests client authentication, the client also sends the client's digital certificate, which binds an identity of the client (e.g., the client name) to a public key of the client (step 108). The client certificate is also typically issued by a certificate authority (CA) which certifies the authenticity of the client certificate by signing the client certificate with its private key.
If the server receives a client certificate, it verifies the CA's signature on the client certificate with the CA's public key, and also verifies that the CA that issued the client certificate is included in the server's list of trusted CAs (step 110). The server also decrypts the master secret with its private key (step 110). The client proves to the server that it holds the private key corresponding to the client certificate with a certificate verify message, which has a hash signed with the client's private key. The hash is computed on all the messages exchanged between the client and server until then, and therefore is a known value to both the client and server.
The client and server then convert the master secret to a set of symmetric keys called session keys. The session keys are known to both the server and client and are used to encrypt and decrypt the subsequent communication between the server and client. The SSL handshake concludes and is followed by a bulk data transfer (step 112) over the communication link encrypted by the session keys.
While SSL allows two parties' communication to be protected against interception from eavesdroppers, the same security mechanism also prevents any attempts by an authorized party (e.g., network administrator) to filter and block the communication of inappropriate and/or not permitted information (i.e., adult content, classified information, etc.) As a result, proxies have been specially designed to filter even encrypted communication between a client and server, often only after obtaining the client's and/or server's permission to do so. Examples of such proxies include Web proxies, data loss prevention (DLP) systems, specialized threat detection solutions, and network intrusion prevention systems (NIPS). These proxies essentially break an SSL connection into two SSL connections: a client-side SSL session between client 10 and proxy 20, and a server-side SSL session between proxy 20 and server 30, as depicted in FIG. 11. These proxies are able to decrypt the encrypted communication and filter the communication in clear text between a client and a server.
While the filtering of encrypted communication by a proxy exists today, there are certain challenges, related to the authentication of devices, created by having a proxy filter SSL communication. These challenges are addressed by embodiments of the present invention, as described below.